HyperLib 1997 Winter - Disc 1/HYPERLIB-1997-Winter-CD1.ISO.7z/HYPERLIB-1997-Winter-CD1.ISO/オンラインウェア/UTIL/GripGrop 1.0.sit/GripGrop 1.0/読まなくてもいいよ１３

Text File | 1996-05-26 | 24KB | 346 lines

■　開発日記　巻之十三

OSTRA / Takeshi Yoneki

{*****}

實篤1.0公開後のバグリスト

１．インデックスのリソースサイズでインデックス数を得るが、ごくまれに戻り値が-1となる可能性があり、そのときはかなり危険な動作がありうる。ただしリソース書込みはないのでログは安全。
２．インライン時にセレクト開始位置を保存していない。
３．メールへの発言やコメントのファイル名とヘッダがメール形式になっていない。
４．HPへの発言やコメントのファイル名が先頭１文字欠ける。
５．新規保存した名前がウィンドウメニューに反映されない。
６．"-"、";"、"/"等のメタキャラクタが「ポストから開く」メニューで解釈される。
７．ATOKのキャプスキーでのメニューの書き換えが即時に反映されない。
８．ダイアログのエディットボックスでのペーストが効かない。
９．インライン途中でのウィンドウ切り替えで日本語入力が誤動作。

1996.04.19

{*****}

注：
　もちろんすべて解決済みです。

{*****}

　使いもしないのにMacWORDをVer.4にアップデートした。もはやVJE-Deltaさえあればいいのだから、店頭でFEPだけ買った方が安いかもしれない。
　で、いつものようにEvenBetterBusErrorを使って動かしてみた。なんと、ついにMacWORDまでもがこのチェックにひっかかるようになってしまった。動作は重くても、最も安心して使えるワープロだっただけに失望は大きい。
　一応バグレポートはFAXしたが、きちんとした対応がないならば、もはやゴミ箱行きは必至。次からはVJEの単体だけ新たに買うかもしれない。
　ＣＯＣＯ姉ちゃんから新しい褌・エディット1.6a1からjgawkが呼べないとの報告。CodeWarriorに移植したときにバグ修正のつもりが、バグを入れこんでいた。

　實篤、GripGrop、褌・エディットの連携実装も大詰めを迎えている。あとは褌・エディットからGripGropを呼び出さなくてはいけない。これだけはC++でなくてPascalなのでコードの使い回しが全く効かない。なんとも二度手間だ。
　GripGropを作って思ったのだが、なんでこういうツールがいままでなかったのだろう。本当はあったんじゃないだろうか。私が知らないだけか？　なかったとは思えない。
　ファイルをテキスト検索するだけのソフトは過去にもいくつかあったことは想像できる。しかし、必要なのはその結果をフォローする環境だ。GripGropはある種のランチャと呼べなくもない。
　結局私の欲しかった環境は、grep結果を使ってタグジャンプすることだった。DOS環境ではgrep、エディタ、シェル（grep結果のリダイレクトのため）がうまく組み合わさって動いている。エディタとシェルをVzだけにしている人も多い。これをどうにかマックに載せたかったのだ。
　タグジャンプする機能を誰が持つとか、ファイルの同定をどうするか（相対パス？絶対パス？）といったことを考えつつ時間ばかりが過ぎていった。Edit7が１つの回答でもあった。これに惑わされていたのかもしれない。多少不自由はしても動いているものがあるというのは、新たに作るという意欲を半減させるものとなるからだ。
　今回、實篤に検索機能を用意しなくてはと思い立って、再び「grep結果を使ってタグジャンプ」の考えがよみがえった。そして、時々思い出しては温めていたアイディアを実装したのである。行番号を使わないというのはアイディアのひとつだ。
　結局はgrepとシェルの機能を持てばいいとわかった。タグジャンプはAppleEventでできると踏んだのであった。
　「超」整理法でのパソコンの使い方に耐えうる検索ツールに仕上がったと思う。
　脆弱だといわれているマックでのテキスト処理が少しでも改善されれば幸いである。

                DOS環境                 GripGrop環境
発見場所        行番号表示              ファイル上のバイト位置
ファイルの同定  基本的に相対パス        ボリューム名＋ディレクトリID
タグジャンプ    エディタが行なう        GripGropからAppleEvent
結果の保存      shellに任せる           GripGropで保存
許容行サイズ    任意だが通常有限        行に依存しない

1996.04.23

{*****}

　GripGropはデフォルトで英語版MS-WORDやDocViewerの文書を検索対象にしている。これらの文書はバイナリファイルなのだが、まあだいたいテキストの部分はそのまま入っているので検索でヒットする。アップルの開発者向け文書は、大昔は英語版MS-WORDで、ちょっと前まではDocViewerで提供されていた。大昔といっても1994年の「develop」のCD-ROMには英語版MS-WORDでのテクニカルノートが入っているのだからそんなに昔でもない。ところが最近、アップルは開発者向け文書をAcrobatで提供するようになっている。これが【倍角開始】「最悪！」【倍角終了】だ。
　Acrobat文書はGripGropでは検索できない。検索対象にしてもかまわないが、何もヒットしないであろう。Acrobatはテキストになんらかのスクランブルをかけている。テキストをテキストとして見ることができないのである。
　Acrobat文書ビュアーに強力かつ高速な複数文書の検索エンジンがあるとかなら文句は言わない。Acrobat文書ビュアーにはこれらの機能が「敢えて」削除されているような気配がある。こんな文書は読めない。どうにも使えない。
　なぜアップルはこんなもので開発者向けドキュメントを配布するのだろう。どう考えても【４倍角開始】「マック向けにアプリケーションを開発して欲しくない」【４倍角終了】としか思えない。
　文書を簡単に転用されたくないという要求に応える技術がAcrobatであることは理解するが、開発者向け文書でそんなことをしてどうするのだろう。文書の電子化の最大の理由と利点は検索性の向上にあるのではなかったか？　検索できない電子文書はただのゴミデータである。紙の方がよっぽどマシだ。私はCodeWarriorをインストールしたら、まずAcrobat文書を全部消している。使えないうえにサイズがでかいからである。
　とにかくAcrobatは最悪。早くなんとかしなさいアップル！

1996.04.24

{*****}

　Info Mac VIIIが送られてきた。そのなかにファイル検索犬ポチというテキスト検索ソフトがあった。もしかして私はいらないソフトを作ってしまったのかと思いつつチェックしてみた。
　いきなり0番地書き込みしてるので、EvenBetterBusErrorをはずして再起動するハメになってしまったが、なかなか面白そうなソフトだ。多少癖はあるが、ある程度機能は豊富のようだ。
　試しに茄子（實篤）ログから「實篤」という文字を検索させた。70秒であった。GripGropは40秒、Edit7が180秒なのでポチは結構速い部類だ。
　よくみると實篤よりポチの方が１件多くヒットしていると気づいた。どこに違いがあるのだろうと調べると、ポチは「實」と「篤」の間に改行があってもヒットさせていると気づいた。GripGropではそれはヒットしない。ポチの方が強力な検索をしているのである。そこがスピードの違いになっている。
　ログファイルの検索をさせるとなると、確かに改行をまたいだ単語の検索のニーズがある。ＣＯＣＯ姉ちゃんも欲しがってたな。こういうことだったのね。
　GripGropのスピードは機能のなさに依存しているようなものなので、これは悩みどころだ。う〜んどうしようなぁ。

1996.04.25

{*****}

注：
　その後結局デリミタ文字を無視するというオプションを用意した。検索スピードを犠牲にしてでも必要な機能と判断。

{*****}

　天王町の蕎麦屋で読売新聞を読んでいたら社会面にこの業界関連の話題が２つ掲載されていた。
　ひとつめ。ＳＣＥ（Sony Computer Entertainment）に公正取引委員会の手が入った。プレイステーションの販売方法にはやはり法的問題があったわけだ。
　「健全な市場形成のためには定価販売を」なんてことをずっといいはってきたが、それを維持するために販売店に圧力かけるなんて大企業のエゴとしかいえないよ。ヤミ再販の疑いがあるそうだけど、どの店いってもどんなクソソフトでも５８００円ってのはないと思うぞ。値段ってのはそれなりに内容判断の基準になってるんだからね。音楽CDと違ってゲームってのは結局手に入れてやってみるまでは結局クソかミソかわかんないんだから。
　もひとつ。毎日コミュニケーションズが写真家から訴えられた。CD-ROM Fanという雑誌でその写真家のCD-ROMに入ってる写真を無断で使用したということで謝罪広告と慰謝料2000万円が請求されている。ついにやったかという事件。やると思ってた思ってた。
　編集部としては忙しいんだかなんだか知らないが事後承諾でどうにでもなると思っていたのだろう。たいていはそれで通ってしまうし、悪意があるわけではないはずだから。だが、問題は事前連絡なしでしかも間違って紹介されたってところだ。片方ならまだしも重なったら言い訳はできまい。編集部のずさんさが完全に露呈したわけだ。以前からいってるが、きちんと雑誌が作れないなら作らなくて結構。そんないいかげんに作られた雑誌なんていらないよ。紙資源の無駄。
　やはり古くからの新聞社系の出版社だってのが問題なのかな。編集サイドは「載せてやってるんだ」って意識を持っていると想像される。それに比べこの業界の出版社はそういう老舗に比べれば桁違いに若いのでそういった意識を感じさせないところがほとんどだ。ＢＮＮもソフトバンクもアスキーも翔泳社もきちんとしている。
　著作権で食ってるくせに他人の著作権に鈍感なのが老舗の新聞社系の出版社の特徴なのかね。パソコン雑誌なんてジャーナリズムでなくて商品カタログだってのに。
　はっきりいいます。「載せてやって」くださらなくて結構です。いや違う。毎日コミュニケーションズの雑誌には私の作品を掲載しないでください。毎日コミュニケーションズの出版物は私の作品の掲載を禁止します。もちろん添付もです。
　読者の知る権利？　読者は他の雑誌やメディアで知ることができるのでいいのです。

1996.05.10

{*****}

　何人かの人から實篤がときどきコケることがあるとの話は届いていたが誰も再現性は追及できなかった、というか追及していなかったのだろう。私の環境では一度も問題の現象を見たことがない。
　安藤さんからの最初のメールは再現性のあるコケのパターンを見つけたというもので、手順が記載されていた。しかしやはり私の環境では再現しなかった。ログファイルに依存する問題は手順での再現性はあまり意味がないのだ。
　で、安藤さんから再びメールで「合計16KByte程度ですがログを送りましょうか」ときた。これは願ったりだった。早速これを受け取って再現させてみた。

　みごとにコケた。

　安定してコケるログだった。追跡を始めた。一覧に表示する形にするインデックスのリンク順序付けが途中で終っていた。５つあるはずの配列の値が２つまでしか埋まってなかった。あとはデタラメな値だ。
　最初の表示ではきちんと表示されるのになぜだろうと疑問を持ちながら、リンク順にする前のリスト作成を追いかけた。なんとも使い勝手が良いとはいえないCodeWarriorのデバッガであちこち見ていたら２つめのインデックスのレスポンスリンクの先がなんとも不可解な値になっていた。
　変なポインタが紛れ込んでいた。ここで気がついた。発言番号からインデックスを引っ張る関数で高速化のためのキャッシュをポインタ１個分保持していたのだ。それはきちんと初期化されているだろうか？　会議室クラスのコンストラクタでは初期化されていた。まてよ、別の会議室に行ってから戻ってきたらコンストラクタなんて通らない。会議室の移動では会議室クラスインスタンスの生成も破棄もあるわけない。しまった、これはインデックスクラスインスタンスを会議室クラスインスタンスに関連付けるときに初期化しなくてはならない。
　というわけで、ありがちな「初期化されていないポインタ問題」だったと判明。間違った値だが、實篤のヒープの中だってことでEvenBetterBusErrorにもひっかからないのであった。
　発言番号からインデックスを引っ張る関数で、要求する発言番号とたまたまメモリに残っていたゴミが一致するための条件を満たしたのが安藤さんの送ってくれたログだった。最初の一回で一致しなければそのポインタは捨てられて問題なく動いてしまう。ログのリンク構造に依存する問題であった。

1996.05.13

{*****}

　パピコンじゃないやポケコンSHARP PB-E500届きました。
　28KByteの広大なメモリ空間！　高速な8bit CPU！　高機能な非構造化BASIC言語！　240*32ドットの精緻なディスプレイ！　どれをとっても二昔前の仕様ですね。今だと安物の電子手帳がこのくらいの仕様かなぁ。あ、でもシリアルポートは9600bpsまであるんだぁ。シリアルインターフェースが見つからなけりゃ意味ないんだけど。
　驚いたのは１２年前に買ったポケコンに比べてかなりでかいことでかいこと。観音開きじゃない分HP 200LXより面積は広い。さすがにHP 200LXの方が厚みはある。
　バッテリーが単４電池ってのが楽でいいね。１２年前のポケコンはボタンタイプの電池で交換が面倒だったおかげで今は見捨てられてしまって久しい。電卓としての需要はあったんで何度か電池交換もしたんだけどね。最近は電卓に不自由していたわけだ。
　電卓の用途はデバッグ時のアドレス計算だから、普通の１６進電卓が一番楽なんだけど多少（ずいぶんと）オーバースペックかもしれない。ま、実に良い高級電卓です（高級な電卓であることは間違いない）。思わぬグレードアップであった。
　でも、でかい。

1996.05.13

{*****}

Date: Tue, 14 May 1996 17:38:12 +0900
To: [e-mail]
Subject: Marking

新田です。

 >> ccに自分を入れるのを忘れたんで、さっきのメール再送してください。

って事で返します。

---------------------------------------------------------------------
>>新田さん
あの後考えていたんですが、前から思っていた「マーキング機能が必要だ」
ということと結局同じだとわかりました。
實篤に発言のマーク機能を用意して、實篤ではそれを「マークした発言にジ
ャンプ」という形で利用すればいいということです。ＵＩ的にはヒストリー
に近いものを想定しています。
マーキングしたときにログと同じ構造でフォルダを作って、各発言対応の
「マークファイル」をネーミングルールを決めて保存するってことで良いと
思います。

        マークフォルダ -+- NIFTY-J -+- マークファイル
                        |           +- マークファイル
                        +- PCVAN
                        +- ASCIINET

ってな構造です。


★ 實篤マーキング機能仕様ドラフト ★

■ マークファイルのネーミングルール

具体例でいうと
        @FMACPRO-003(001)-956
が基本、ログファイルの"#"を"@"にして、後ろに発言番号を付加します。
発言番号が0のばあいがあるので、そういうものは
        @MAIL-001(001)-0-1
といった形になります。発言番号の後に単純に順序数を付け加えます。
使ったマークファイルは"@"を"_"にでもすればよいでしょう。實篤では"@"
を付けたファイルのみ見るようにします。オプションで"_"で始まるファイ
ルの削除を用意してもいいですしね。

■ マークファイル内容

具体例でいうと
----------
956, 0, 96.05.14, 1
GCC01675
OSTRA
デバッグ協力要請
----------
内容は
----------
発言番号, リンク先, 年月日, 既読等フラグ
ID
ハンドル
タイトル
----------
でまずは始めます。

■ マークファイルの属性

クリエータ: 'HunB'
ファイルタイプ: 'Mark'

では意見をお願いします。

Takeshi Yoneki

E-mail : [e-mail]
Nifty-Serve : GCC01675
米木　武

{*****}

Date: Tue, 14 May 1996 19:25:27 +0900
To: Takeshi Yoneki <[e-mail]>
Subject: Re: simatta2

Takeshi Yoneki さんが 96/05/14ごろに「simatta2」の件で以下の様に書きました：

 >> またccに自分を忘れてしまいました。転送よろしく。

なんだかなぁ

------------------------------------------------------------------------
Subject: Re^2: Marking
Date: Tue, 14 May 96 19:03:52 +0900
From: Takeshi Yoneki <[e-mail]>

> これって、自由にマークフォルダーの場所を決められるってことでしょうか？

基本的にログフォルダとかポストフォルダと同じような扱いで考えていま
す。Prefファイルの中身を教えてもいいのですが、バイナリファイルなんで
リソースじゃないですよ。XCMDでやらないといけないでしょうね。

> これだけあればパーフェクトです。最初の行に、識別できる何かがあると

そうですね、ネーミングだけでなくマジックナンバーに相当する何かがあっ
た方がいいかもしれませんね。
實篤はファイルタイプでもチェックできますが、ツールは一般的なテキスト
でも動ければ手動で動作させることもできますね。

----------
MARKFILE
956, 0, 96.05.14, 1, 222
GCC01675
OSTRA
デバッグ協力要請
----------
内容は
----------
MARKFILE（固定文字列）
発言番号, リンク先, 年月日, 既読等フラグ, 本文サイズ
ID
ハンドル
タイトル
----------
とでも改定しましょう。

> 確か、ファイルタイプ: 'TEXT'　でないとHyperCardの標準では読めなかった
> 気がします。まあXCMDで読めば読めますが.....

これはちょっと曲げられませんね、'TEXT'はログだと茄子で決められてしま
ってますから。XCMDでがんばるしかないでしょうね。
XCMDってTHINK Cで作るって意味かな？

>>島川氏はマック使いだったっけ？？

楽しいこと始めてるよんとccで見せて悔しがらせてるだけです(^^)
マック買えば参加できるのにねぇ。

このマーキング機能は「栞」と表現することに決まりました。
読めるかな？ ちゃんとwnnの辞書には入ってたな、えらいえらい。

Takeshi Yoneki

E-mail : [e-mail]
Nifty-Serve : GCC01675
米木　武

{*****}

注：
　栞ファイルの正式な仕様は實篤・取扱説明書を参照してください。微妙に変化してます。

{*****}

　茄子Ｒ0.3βが公開された。起動時のログの正当性のチェックをはずしたそうで起動はやたらと速くなっている。實篤の起動速度は普通に作った結果なのでどうでもいいことなのだが、ユーザにとってみれば非常にアピールした部分であった。とりあえずそのへんでの優位はなくなったと思う。實篤はある程度の正当性のチェックをオンデマンドでやっている（最初に一気にやるのでなく必要になったときにやってるってこと。負荷の分散ともいう）。まさか茄子Ｒ0.3βはそれさえやめたのではあるまいな。
　機能性に関して實篤が茄子Ｒに影響を与えたのは事実であろう。もちろん實篤だって茄子Ｒを参考にした部分はある。この点は「良いアイディアはどんどん採用する」でいいと思う。
　問題は安定性だ。安定性に関してはドキュメントにも「まだ不安定な部分がある」と書いてあるので、この１つ前のバージョンよりレベルダウンしている可能性がある。まあ、使わないから確認はできない。
　安定性は機能と違って真似できない部分なので茄子Ｒの不安定さは簡単には解消しないであろう。茄子Ｒが安定したなら實篤の役割は終わるのだが、その日が来るとは到底想像できない。YooEditが安定したらHUNDOSHI-EDITの役割は終えると思っていたのだが全然安定する気配もない。
　で、もうひとつ問題は茄子Ｒ0.3βでは'Pnut'でないクリエータのログファイルを読まなくなったことだ。共存可能と思っていたし、併用しているユーザも多いというのに。
　ともかくこれで實篤と茄子Ｒは住み分けなくてはいけないことになってしまった。私としては實篤の方がマイナーな存在でいたいと思っている。ともかく高機能化は私の性に合わない。高機能なログブラウザを使いたい方は茄子Ｒをどうぞ。
　ああ、高機能化がなんで嫌いなのかを説明しなかったな。やはりSoftware Toolsという考え方が好きだからということに尽きる。インターフェースがオープンになっている複数のツールを組み合わせてなんとかするってのが基本だと思っている。そう、UNIXやOpenDocの基本的な考え方そのものだね。まあ、バイナリサイズでは實篤は茄子Ｒより大きくなってしまってるんだけど(^^;)。
　地味にいきましょう。

1996.05.16

{*****}

注：
　茄子Ｒ0.3βは起動時のチェックを会議室選択時に変更したそうで、チェックがなくなったわけではないとのことです。
　また、とりあえず一方的に共存可能にするためのオプションを實篤に用意しました。

{*****}

　茄子Ｒ0.3βでなぜ'Pnut'のファイルしか読まなくなったのか考えていた。最初は實篤バッシング以外の考えは浮かばなかったが、一つ別の技術的予測が浮かんできた。
　ともかく實篤の起動スピードが衝撃的だったのは事実であろう。で、「本当は茄子Ｒは大切なログファイルチェックを起動時にやってるのに、それを怠ってる實篤が好評なのはいやだなぁ。どうせユーザなんてそういう重要なことがわかんないのサ！」とでも考えたかどうかはわからないが、その結果として起動時のファイルチェックを非常に簡単なものに書き換えたのだと思える。
　ファイルチェックをどのように書き換えたのか？　それを説明する前に、オリジナル茄子の起動時のログファイルチェックを挙げる。１つ前のバージョンの茄子Ｒまでは同じだったと思われる。
　　１．ファイル名がネーミングルールに合っているかのチェック
　　２．リソースが全部揃っているかのチェック
　實篤はリソースチェックを起動時から会議室選択時に移した（というか最初からそう実装した）。これが負荷分散となった。
　茄子Ｒ0.3βは少なくともリソースチェックは起動時にはしなくなった。ネーミングルールチェックをどうしたかは実験が必要だが作者本人に尋ねるのがいちばんよい。
　ポイントはリソースチェックを省略した代りに新しい別のチェックを入れたのではないかということだ。
　　３．クリエータが'Pnut'かどうかのチェック
　理由は次のように考えられる。「リソースのチェックを外すだけではやはり不安なので、確実にログファイルと判断できる'Pnut'かどうかのチェックを新たに入れることにすれば良いだろう」「さいわいなことにファイルタイプのチェックはほとんど負荷がない」ということではないだろうか？
　まいったね。
　この件に関して何が問題かというと、茄子形式ログファイルは'TEXT'というファイルタイプなのである。この'TEXT'というファイルタイプはあらゆるエディタやワープロが使うので結局は「ファイルタイプでは何も判断しない」という了解の上でしか使えない。そしてこの「ファイルタイプでは何も判断しない」という了解は「できればクリエータでも何も判断しない」という合意につながる（NisusWriterは明確にこれを破っている）。
　オリジナル茄子がログファイルを別のファイルタイプにしていたなら何の問題もなかったのであるが、'TEXT'を使った（当時のエディタは'TEXT'しか開けないものが多かったのが理由と推測される）ため、「ログファイルかどうか」のチェックが必要になったと私は解釈している。
　クリエータチェックを導入してもしなくても結果は同じだということは少し考えればすぐわかる。クリエータチェックの導入理由は「不安なので」以外になく、実はこれは全く根拠を持たない。
　茄子形式ログファイルは、指定したフォルダに作られるという前提条件があるかぎり、ネーミングルールチェックを通るファイルは茄子形式ログファイルの有力候補と考えてよいことになる。逆に、壊れた茄子形式リソースを持つファイルは茄子形式ログファイル以外にはなく、壊れた茄子形式リソースを持つのは普通'Pnut'のクリエータを持つ（ほとんどの茄子向けログファイルを作るツールは'Pnut'の'TEXT'を作るため）。
　そもそも茄子形式ログファイルを作るツールは「ブラウザ」側ではない。ひとつの可能性としてツールのクリエータを持つ'TEXT'というものが存在しうる（たまたまこれまではなかったわけだ）。こういった'TEXT'を排除してしまうのはログブラウザの要求される仕様から外れていると思う。

転載自由
転載後メール

1996.05.17

{*****}

　フォルダ設定に関しては暫定的な処置であったことは事実です。ただし、頻繁に使うことのない部分のため後回しになったわけです。必要な最低限の機能に優先度を付けて実装するというのは初期開発においてあたりまえなことです。最初のリリース後、他のアプリでフォルダ設定向けに標準ファイルパッケージを使うというクラスを用意したので、それを使うようになります。けして「DOSライク」にしようとしたわけではありません。簡便にフォルダを指定させる場合に他にどういう方法があるか示してください。パス指定は初期のHyperCardでも使われた手法です。ScriptEditorでも似たような状況だと思いましたがこれは改善されたのかな？　まあ、UI的に誉められたものではありませんが。
　その「DOSライク」なエディタが他のエディタの機能に影響を与えたことも事実です。「DOS」に似ている似ていないというレベルの低い評は意義があるとは思えません。ところでそんなに「DOSライク」でしたか？　ステータス行、ファイル終端記号、改行記号、コントロールコードの表示以外に似ていると感じさせる部分は私には思い当たりません。これらの機能はその後他のエディタに多く取り入れられているものです。けして本来DOS固有のものでないのです。「DOS」でも便利な部分はどんどん取り入れるべきなのです。キャッチコピーとして「DOSライク」を使ったのは私自身ですが、なんらかの評価基準として、また否定的な意味で使った覚えはありません。
　あと、安定性を見習うというのは非常に難しいことです。安定性の確保や維持にどんなに労力が必要かは開発者でなければわからない事なのかもしれません。
　實篤の機能が少ないのは事実ですので、それはかまいません。機能の豊富さでアプリケーションを選定するのは一般的なことです。機能の量と安定度というのはある程度相反するもので、安定化にかかるコストはソフト開発の中で不当に過小評価されている部分でしょう。
　實篤は安定性の意義を理解した人にのみ使ってほしいのです。
　機能が少ないのはユーザを選別するためです。「安定してるが機能の少ない茄子」というのは實篤の基本コンセプトです。

1996.05.17

{*****}

　褌・エディットの積年の問題点にメスを入れた。インライン入力のチューンアップである。
　これまでの褌・エディットのインライン入力はそもそもTSMインラインのことを考えずに実装したものに無理矢理対応させたがゆえの動作のぎこちなさが目立っていた。テキストの挿入と削除が独立に実装されていたためインライン入力時に全体がちらちらし、無駄な動きが多かった。今回のバージョンはようやくこれを「挿入と削除が融合した処理」を用意することで対応した。いやはや長かった。
　もはやこの辺の処理は他人の書いたソースに等しい。ともかく現状で何をやっているのかの詳しい解読・理解に骨が折れた。
　ついでにバグの原因となる部分も発見し、比較的まれにウィンドウ外の画面データがテキストのある部分にコピーされるという問題も解消したのではないかと見ている。問題がなくなったかどうかはこれからのロードテストで判明するだろう。
　ともかくやっとこれでインライン入力がぎこちないというのはなくなった。以前よりは大分入力スピードも速くなるであろう。置き換えの処理は今まですべていったん削除してから挿入という処理を経ていたのだが、いわゆるペーストもフィルタも削除処理が見えなくなった。

1996.05.21

{*****}

　去年のマックデベジャ「特集・スプリプティング時代の始動」をひっぱりだしてきて「Open Scripting Architecture」を読むと、AppleEventやOSA関連で頼れる解説記事は「Apple Object and You」と「Better Apple Event Coding Through Objects」があるとわかります。「Apple Object and You」はいずれ読もうと以前にプリントアウト（developのCD-ROMから）して積ん読してたのですが、邦訳がマックデベジャのバックナンバーにあることもわかりました。
　インサイドマックの「Interapplication Communication」とそのマックデベジャのバックナンバーを手に入れようと新宿、お茶の水、秋葉原と歩きました。疲れました。
　IMのIACは結局のところ新宿紀伊国屋、新宿さくらやOA館、新宿三省堂、お茶の水丸善、お茶の水三省堂、お茶の水書泉グランテ、LAOXマック館のどこにもなく、「ここになかったらBergさんに文句を言おう」と思いつつMaxBugにいったらドーンと並んでました。
　マックデベジャのバックナンバーはもちろんどこにもありません。
　で、ついでに六角さん推薦の「Macintoshプロフェッショナルプログラミング」も買ってきました。買う前に目次を読んだのですが、これはタイトルが悪いですね。多くのページがAppleEvent、OSA、AppleScriptの話ですから、そういったことがわかるタイトルじゃないとなかなか気づかない。あまりにも一般的なタイトルすぎます。
　で、帰ってきてから良く見るとなんと「Apple Object and You」と「Better Apple Event Coding Through Objects」の邦訳が付録の形で収録されてるではないですか！　それを先にいいなさい！
　IMのIACの邦訳版がほしいなぁ。

1996.05.25

{*****}